feat(api): add CRUD and validation for webhook configurations

What this PR Provides

This PR introduces the API endpoints for managing (CRUD) inbound webhook configurations.
It establishes the foundation for receiving data from external systems by allowing users to define how incoming payloads should be mapped to entities.

The core logic of this PR includes:

• CRUD API for Webhooks: Implementation of the following endpoints:
  • POST /api/v1/inbound-webhooks: To create a new webhook configuration.
  • GET /api/v1/inbound-webhooks: To list all existing configurations.
  • GET /api/v1/inbound-webhooks/{identifier}: To retrieve a specific configuration.
  • PUT /api/v1/inbound-webhooks/{identifier}: To update an existing configuration.
  • DELETE /api/v1/inbound-webhooks/{identifier}: To delete a configuration.
• JSLT Mapping Validation: Upon creation (POST) or update (PUT), the backend now validates the syntax of all JSLT expressions provided in the mappings array. This prevents saving configurations with invalid transformation logic.
• Security Scheme Validation: The configuration now accepts and validates a security object with specific types. The supported types are:
  • HMAC_SHA256: For signature validation using a shared secret (e.g., GitHub, Sonar).
  • STATIC_TOKEN: For simple authentication using a static token in a header.

Review

The reviewer must double-check these points:

• The reviewer has tested the feature
• The reviewer has reviewed the implementation of the feature
• The documentation has been updated
• The feature implementation respects the Technical Doc / ADR previously produced

How to test

1. Initial State

• The application is running.
• No webhook configurations exist initially.

2. What and how to test

A. Create a Valid Webhook Configuration

1. Send a POST request to /api/v1/inbound-webhooks with the following JSON body:

   {
     "identifier": "sonar_webhook",
     "title": "Sonar Webhook",
     "enabled": true,
     "mappings": [
       {
         "template": "sonar_project",
         "filter": ".visibility == \"private\"",
         "entity": {
           "identifier": ".key | tostring",
           "title": ".name",
           "properties": {
             "project_name": ".name | tostring"
           }
         }
       }
     ],
     "security": {
       "type": "HMAC_SHA256",
       "config": {
         "header_name": "X-Sonar-Webhook-HMAC-SHA256",
         "secret_alias": "SONAR_WEBHOOK_SECRET"
       }
     }
   }

2. Expected Result: The request succeeds with a 201 Created status, and the response body contains the created configuration.

B. Attempt to Create a Configuration with Invalid JSLT

1. Send a POST request to /api/v1/inbound-webhooks with a malformed JSLT expression (e.g., a missing quote):

   {
     "identifier": "invalid_jslt_webhook",
     "title": "Invalid JSLT",
     "mappings": [
       {
         "template": "test",
         "entity": { "identifier": ".key | tostring(" }
       }
     ]
   }

2. Expected Result: The request fails with a 400 Bad Request status, and the error message indicates a JSLT syntax validation error.

C. Attempt to Create a Configuration with an Invalid Security Type

1. Send a POST request to /api/v1/inbound-webhooks with an unsupported security type:

   {
     "identifier": "invalid_security_webhook",
     "title": "Invalid Security",
     "mappings": [
       {
         "template": "test",
         "entity": { "identifier": ".key" }
       }
     ],
     "security": {
       "type": "INVALID_TYPE"
     }
   }

2. Expected Result: The request fails with a 400 Bad Request status, and the error message indicates that the security type is not supported.

D. Read, Update, and Delete the Configuration

1. GET: Send a GET request to /api/v1/inbound-webhooks/sonar_webhook.
   • Expected Result: The request succeeds with a 200 OK status and returns the full configuration for sonar_webhook.
2. PUT: Send a PUT request to /api/v1/inbound-webhooks/sonar_webhook with "enabled": false.
   • Expected Result: The request succeeds with a 200 OK status. A subsequent GET request should show "enabled": false.
3. DELETE: Send a DELETE request to /api/v1/inbound-webhooks/sonar_webhook.
   • Expected Result: The request succeeds with a 204 No Content status.
4. Verify Deletion: Send a GET request to /api/v1/inbound-webhooks/sonar_webhook.
   • Expected Result: The request fails with a 404 Not Found status.

Breaking changes (if any)

• N/A